क्रॉस-ऍप्लिकेशन कम्युनिकेशनमध्ये प्रभुत्व मिळवणे: फ्रंटएंड मायक्रो-फ्रंटएंड इव्हेंट बस

आधुनिक वेब डेव्हलपमेंटच्या क्षेत्रात, मायक्रो-फ्रंटएंड्स एक शक्तिशाली आर्किटेक्चरल पॅटर्न म्हणून उदयास आले आहेत. ते टीम्सना यूजर इंटरफेसचे स्वतंत्र भाग तयार करण्यास आणि तैनात करण्यास परवानगी देतात, ज्यामुळे चपळता, स्केलेबिलिटी आणि टीम स्वायत्तता वाढते. तथापि, जेव्हा या स्वतंत्र ऍप्लिकेशन्सना एकमेकांशी संवाद साधण्याची आवश्यकता असते तेव्हा एक गंभीर आव्हान निर्माण होते. एका मजबूत यंत्रणेशिवाय, मायक्रो-फ्रंटएंड्स वेगळी बेटे बनू शकतात, ज्यामुळे वापरकर्त्यांना अपेक्षित असलेला एकसंध वापरकर्ता अनुभव बाधित होतो. इथेच फ्रंटएंड मायक्रो-फ्रंटएंड इव्हेंट बस महत्त्वाची भूमिका बजावते, जी क्रॉस-ऍप्लिकेशन कम्युनिकेशनसाठी केंद्रीय मज्जासंस्था म्हणून काम करते.

मायक्रो-फ्रंटएंड लँडस्केप समजून घेणे

इव्हेंट बसबद्दल जाणून घेण्यापूर्वी, चला मायक्रो-फ्रंटएंड्सचा संदर्भ थोडक्यात पुन्हा स्थापित करूया. एका मोठ्या ई-कॉमर्स प्लॅटफॉर्मची कल्पना करा. एकाच, मोनोलिथिक फ्रंटएंड ऍप्लिकेशनऐवजी, आपल्याकडे हे असू शकते:

• एक प्रॉडक्ट कॅटलॉग मायक्रो-फ्रंटएंड: उत्पादनांची सूची, शोध आणि फिल्टरिंग प्रदर्शित करण्यासाठी जबाबदार.
• एक शॉपिंग कार्ट मायक्रो-फ्रंटएंड: कार्टमध्ये जोडलेल्या वस्तू, त्यांची संख्या आणि चेकआउट सुरू करण्याचे व्यवस्थापन करते.
• एक यूजर प्रोफाइल मायक्रो-फ्रंटएंड: वापरकर्ता प्रमाणीकरण, ऑर्डर इतिहास आणि वैयक्तिक तपशील हाताळते.
• एक शिफारस इंजिन मायक्रो-फ्रंटएंड: वापरकर्त्याच्या वर्तनावर आधारित संबंधित उत्पादने सुचवते.

यापैकी प्रत्येक वेगवेगळ्या टीम्सद्वारे स्वतंत्रपणे विकसित, तैनात आणि देखरेख केले जाऊ शकते. याचे महत्त्वपूर्ण फायदे आहेत:

• तंत्रज्ञान विविधता: टीम्स त्यांच्या विशिष्ट मायक्रो-फ्रंटएंडसाठी सर्वोत्तम तंत्रज्ञान स्टॅक निवडू शकतात.
• टीम स्वायत्तता: डेव्हलपमेंट टीम्स जास्त समन्वयाशिवाय स्वतंत्रपणे काम करू शकतात.
• जलद उपयोजन सायकल: लहान, स्वतंत्र उपयोजनामुळे धोका कमी होतो आणि वेग वाढतो.
• स्केलेबिलिटी: मागणीनुसार वैयक्तिक मायक्रो-फ्रंटएंड्स स्केल केले जाऊ शकतात.

आव्हान: आंतर-ऍप्लिकेशन कम्युनिकेशन

स्वतंत्र डेव्हलपमेंटच्या सौंदर्यासह एक मोठे आव्हान येते: हे वेगळे ऍप्लिकेशन्स एकमेकांशी कसे बोलतात? या सामान्य परिस्थितींचा विचार करा:

• जेव्हा एखादा वापरकर्ता शॉपिंग कार्टमध्ये एखादी वस्तू जोडतो, तेव्हा प्रॉडक्ट कॅटलॉगला कदाचित हे सूचित करावे लागेल की ती वस्तू आता कार्टमध्ये आहे (उदा. चेकमार्क).
• जेव्हा एखादा वापरकर्ता यूजर प्रोफाइल मायक्रो-फ्रंटएंडद्वारे लॉग इन करतो, तेव्हा इतर मायक्रो-फ्रंटएंड्सना (जसे की शिफारस इंजिन) वापरकर्त्याची प्रमाणीकरण स्थिती जाणून घ्यावी लागेल जेणेकरून सामग्री वैयक्तिकृत करता येईल.
• जेव्हा एखादा वापरकर्ता खरेदी करतो, तेव्हा शॉपिंग कार्टला प्रॉडक्ट कॅटलॉगला इन्व्हेंटरीची संख्या अपडेट करण्यासाठी किंवा यूजर प्रोफाइलला नवीन ऑर्डर इतिहास दर्शवण्यासाठी सूचित करावे लागेल.

मायक्रो-फ्रंटएंड्समधील थेट कम्युनिकेशनला अनेकदा परावृत्त केले जाते कारण ते घट्ट कपलिंग तयार करते, ज्यामुळे मायक्रो-फ्रंटएंड आर्किटेक्चरचे अनेक फायदे नाकारले जातात. त्यांच्यात संवाद साधण्यासाठी आपल्याला एक शिथिल-जोडलेली, लवचिक आणि स्केलेबल पद्धत आवश्यक आहे.

फ्रंटएंड मायक्रो-फ्रंटएंड इव्हेंट बसची ओळख

एक इव्हेंट बस, ज्याला मेसेज बस किंवा पब/सब (पब्लिश-सबस्क्राइब) सिस्टम म्हणूनही ओळखले जाते, हे एक डिझाइन पॅटर्न आहे जे ऍप्लिकेशनच्या विविध भागांमध्ये डिकपल्ड कम्युनिकेशन सक्षम करते. मायक्रो-फ्रंटएंड्सच्या संदर्भात, ते एक केंद्रीय केंद्र म्हणून काम करते जेथे ऍप्लिकेशन्स इव्हेंट्स प्रकाशित करू शकतात आणि इतर ऍप्लिकेशन्स या इव्हेंट्ससाठी सबस्क्राइब करू शकतात.

यामागील मूळ कल्पना सोपी आहे:

• प्रकाशक (Publisher): एक ऍप्लिकेशन जो एक इव्हेंट तयार करतो आणि तो बसवर प्रसारित करतो.
• ग्राहक (Subscriber): एक ऍप्लिकेशन जो बसवरील विशिष्ट इव्हेंट्स ऐकतो आणि ते घडल्यावर प्रतिक्रिया देतो.
• इव्हेंट बस (Event Bus): मध्यस्थ जो प्रकाशित इव्हेंट्स सर्व इच्छुक ग्राहकांपर्यंत पोहोचवण्याची सोय करतो.

हे पॅटर्न ऑब्झर्व्हर पॅटर्नशी जवळून संबंधित आहे, जेथे एक ऑब्जेक्ट (विषय) त्याच्या अवलंबितांची (निरीक्षक) यादी ठेवतो आणि त्यांच्या स्थितीतील कोणत्याही बदलांबद्दल त्यांना आपोआप सूचित करतो, सामान्यतः त्यांच्यापैकी एका पद्धतीला कॉल करून.

मायक्रो-फ्रंटएंड्ससाठी इव्हेंट बसची मुख्य तत्त्वे

1. डिकपलिंग: प्रकाशक आणि ग्राहकांना एकमेकांच्या अस्तित्वाबद्दल माहिती असणे आवश्यक नाही. ते फक्त इव्हेंट बसद्वारे संवाद साधतात.
2. असिंक्रोनस कम्युनिकेशन: इव्हेंट्स सामान्यतः असिंक्रोनसपणे प्रक्रिया केले जातात, म्हणजे प्रकाशकाला ग्राहकांच्या इव्हेंटवर प्रक्रिया पूर्ण होण्याची प्रतीक्षा करावी लागत नाही.
3. स्केलेबिलिटी: जसे अधिक मायक्रो-फ्रंटएंड्स जोडले जातात, ते फक्त विद्यमान घटकांना प्रभावित न करता इव्हेंट्ससाठी सबस्क्राइब करू शकतात किंवा प्रकाशित करू शकतात.
4. केंद्रीकृत लॉजिक (इव्हेंट्ससाठी): जरी ऍप्लिकेशन लॉजिक वितरित असले तरी, इव्हेंट हाताळणीची यंत्रणा बसद्वारे केंद्रीकृत असते.

तुमच्या मायक्रो-फ्रंटएंड इव्हेंट बसची रचना करणे

मायक्रो-फ्रंटएंड इव्हेंट बस लागू करण्यासाठी अनेक पद्धती आहेत, प्रत्येकाचे फायदे आणि तोटे आहेत. निवड अनेकदा तुमच्या ऍप्लिकेशनच्या विशिष्ट गरजा, वापरलेले तंत्रज्ञान आणि उपयोजन धोरणावर अवलंबून असते.

१. ग्लोबल इव्हेंट एमिटर (जावास्क्रिप्ट)**

ही एक सामान्य आणि तुलनेने सोपी पद्धत आहे जी एकाच ब्राउझर संदर्भात तैनात केलेल्या मायक्रो-फ्रंटएंड्ससाठी (उदा. मॉड्यूल फेडरेशन किंवा iframe कम्युनिकेशन वापरून) उपयुक्त आहे. एकच, सामायिक जावास्क्रिप्ट ऑब्जेक्ट इव्हेंट बस म्हणून काम करतो.

अंमलबजावणीचे उदाहरण (संकल्पनात्मक जावास्क्रिप्ट)

आपण एक साधा इव्हेंट एमिटर क्लास तयार करू शकतो:

            class EventBus {
  constructor() {
    this.listeners = {};
  }

  subscribe(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
    return () => {
      this.unsubscribe(event, callback);
    };
  }

  unsubscribe(event, callback) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event] = this.listeners[event].filter(listener => listener !== callback);
  }

  publish(event, data) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event].forEach(callback => {
      try {
        callback(data);
      } catch (error) {
        console.error(`Error in event handler for ${event}:`, error);
      }
    });
  }
}

// In your main application shell or a shared utility file:
export const sharedEventBus = new EventBus();

            

              
                Copy
              
            
          

मायक्रो-फ्रंटएंड्स ते कसे वापरतात

प्रॉडक्ट कॅटलॉग मायक्रो-फ्रंटएंड (प्रकाशक):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

function handleAddToCartButtonClick(productId) {
  // ... logic to add item to cart ...
  sharedEventBus.publish('itemAddedToCart', { productId: productId, quantity: 1 });
}

            

              
                Copy
              
            
          

शॉपिंग कार्ट मायक्रो-फ्रंटएंड (ग्राहक):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

// When the cart component mounts or initializes
const subscription = sharedEventBus.subscribe('itemAddedToCart', (eventData) => {
  console.log('Item added to cart:', eventData);
  // Update cart UI, add item to internal state, etc.
  updateCartUI(eventData.productId, eventData.quantity);
});

// Remember to unsubscribe when the component unmounts to prevent memory leaks
// componentWillUnmount() { subscription(); }

            

              
                Copy
              
            
          

ग्लोबल इव्हेंट एमिटर्ससाठी विचार करण्यासारख्या गोष्टी

• स्कोप: ही पद्धत तेव्हा चांगली काम करते जेव्हा मायक्रो-फ्रंटएंड्स एकाच ब्राउझर विंडोमध्ये लोड केलेले असतात आणि एक ग्लोबल स्कोप किंवा एक सामान्य मॉड्यूल सिस्टम (जसे की वेबपॅकचे मॉड्यूल फेडरेशन) शेअर करतात.
• मेमरी लीक्स: मेमरी लीक टाळण्यासाठी जेव्हा मायक्रो-फ्रंटएंड घटक अनमाउंट केले जातात तेव्हा योग्य अनसबस्क्रिप्शन यंत्रणा लागू करणे महत्त्वाचे आहे.
• इव्हेंट नेमिंग कन्व्हेन्शन्स: संघर्ष टाळण्यासाठी आणि देखभाल सुलभ करण्यासाठी इव्हेंट्ससाठी स्पष्ट नामकरण नियम स्थापित करा. उदाहरणार्थ, [micro-frontend-name]:eventName सारखा उपसर्ग वापरा.
• डेटा स्ट्रक्चर: इव्हेंट्ससाठी सुसंगत डेटा स्ट्रक्चर्स परिभाषित करा.

२. कस्टम इव्हेंट्स आणि DOM डिस्पॅचिंग

दुसरी ब्राउझर-नेटिव्ह पद्धत DOM चा कम्युनिकेशन चॅनेल म्हणून वापर करते. मायक्रो-फ्रंटएंड्स एका सामायिक DOM घटकावर (उदा. `window` ऑब्जेक्ट किंवा नियुक्त कंटेनर घटक) कस्टम इव्हेंट्स डिस्पॅच करू शकतात आणि इतर मायक्रो-फ्रंटएंड्स हे इव्हेंट्स ऐकू शकतात.

अंमलबजावणीचे उदाहरण (संकल्पनात्मक जावास्क्रिप्ट)

प्रॉडक्ट कॅटलॉग मायक्रो-फ्रंटएंड (प्रकाशक):

            
function handleAddToCartButtonClick(productId) {
  const event = new CustomEvent('microfrontend:itemAddedToCart', {
    detail: { productId: productId, quantity: 1 }
  });
  window.dispatchEvent(event);
}

            

              
                Copy
              
            
          

शॉपिंग कार्ट मायक्रो-फ्रंटएंड (ग्राहक):

            
const handleItemAdded = (event) => {
  console.log('Item added to cart:', event.detail);
  updateCartUI(event.detail.productId, event.detail.quantity);
};

window.addEventListener('microfrontend:itemAddedToCart', handleItemAdded);

// Remember to remove the listener when the component unmounts
// window.removeEventListener('microfrontend:itemAddedToCart', handleItemAdded);

            

              
                Copy
              
            
          

कस्टम इव्हेंट्ससाठी विचार करण्यासारख्या गोष्टी

• ब्राउझर कंपॅटिबिलिटी: `CustomEvent` मोठ्या प्रमाणावर समर्थित आहे, परंतु तरीही पडताळणी करणे चांगले आहे.
• डेटा ट्रान्सफर मर्यादा: `CustomEvent` ची `detail` प्रॉपर्टी कोणताही सीरियलाइजेबल डेटा हस्तांतरित करू शकते.
• ग्लोबल नेमस्पेस प्रदूषण: `window` वर इव्हेंट्स डिस्पॅच केल्याने जर काळजीपूर्वक व्यवस्थापन केले नाही तर नावांमध्ये संघर्ष होऊ शकतो.
• परफॉर्मन्स: खूप जास्त प्रमाणात इव्हेंट्ससाठी, हे समर्पित इव्हेंट एमिटरच्या तुलनेत सर्वात कार्यक्षम समाधान असू शकत नाही.

३. मेसेज क्यू किंवा बाह्य ब्रोकर्स (अधिक गुंतागुंतीच्या परिस्थितीसाठी)

जेव्हा मायक्रो-फ्रंटएंड्स वेगवेगळ्या ब्राउझर संदर्भांमध्ये (उदा. वेगवेगळ्या ओरिजिनमधील iframes) चालू शकतात, किंवा जर तुम्हाला अधिक मजबूत वैशिष्ट्ये जसे की गॅरंटीड डिलिव्हरी, मेसेज पर्सिस्टन्स, किंवा सर्व्हर-साइड घटकांवर ब्रॉडकास्टिंगची आवश्यकता असेल, तर तुम्ही बाह्य मेसेज क्यू सिस्टम्सचा वापर करण्याचा विचार करू शकता.

उदाहरणांमध्ये हे समाविष्ट आहे:

• वेबसॉकेट्स: रिअल-टाइम, द्विदिशात्मक कम्युनिकेशनसाठी.
• सर्व्हर-सेंट इव्हेंट्स (SSE): एक-मार्गी सर्व्हर-ते-क्लायंट कम्युनिकेशनसाठी.
• डेडिकेटेड मेसेज ब्रोकर्स: जसे की RabbitMQ, Apache Kafka, किंवा क्लाउड-आधारित सोल्यूशन्स (AWS SQS/SNS, Google Cloud Pub/Sub).

अंमलबजावणीचे उदाहरण (संकल्पनात्मक - वेबसॉकेट्स)

एक बॅकएंड वेबसॉकेट सर्व्हर केंद्रीय ब्रोकर म्हणून काम करतो.

प्रॉडक्ट कॅटलॉग मायक्रो-फ्रंटएंड (प्रकाशक):

            
// Assuming a WebSocket connection is established and managed globally
function handleAddToCartButtonClick(productId) {
  if (websocketConnection.readyState === WebSocket.OPEN) {
    websocketConnection.send(JSON.stringify({
      event: 'itemAddedToCart',
      data: { productId: productId, quantity: 1 }
    }));
  }
}

            

              
                Copy
              
            
          

शॉपिंग कार्ट मायक्रो-फ्रंटएंड (ग्राहक):

            
// Assuming a WebSocket connection is established and managed globally
websocketConnection.onmessage = (event) => {
  const message = JSON.parse(event.data);
  if (message.event === 'itemAddedToCart') {
    console.log('Item added to cart (from WS):', message.data);
    updateCartUI(message.data.productId, message.data.quantity);
  }
};

            

              
                Copy
              
            
          

बाह्य ब्रोकर्ससाठी विचार करण्यासारख्या गोष्टी

• इन्फ्रास्ट्रक्चर ओव्हरहेड: एक वेगळी सेवा सेट अप करणे आणि व्यवस्थापित करणे आवश्यक आहे.
• लेटन्सी: कम्युनिकेशन सामान्यतः सर्व्हरद्वारे होते, ज्यामुळे लेटन्सी येऊ शकते.
• गुंतागुंत: इन-ब्राउझर सोल्यूशन्सपेक्षा सेट अप करणे आणि व्यवस्थापित करणे अधिक गुंतागुंतीचे आहे.
• स्केलेबिलिटी आणि विश्वसनीयता: अनेकदा उच्च स्केलेबिलिटी आणि विश्वसनीयतेची हमी देते.
• क्रॉस-ओरिजिन कम्युनिकेशन: वेगवेगळ्या ओरिजिनमधील iframes साठी आवश्यक.

मायक्रो-फ्रंटएंड इव्हेंट बस लागू करण्यासाठी सर्वोत्तम पद्धती

कोणतीही अंमलबजावणी निवडली तरी, सर्वोत्तम पद्धतींचे पालन केल्याने एक मजबूत आणि देखरेख करण्यायोग्य प्रणाली सुनिश्चित होईल.

१. इव्हेंट्ससाठी एक स्पष्ट करार परिभाषित करा

प्रत्येक इव्हेंटची एक सु-परिभाषित रचना असावी. यात समाविष्ट आहे:

• इव्हेंटचे नाव: एक अद्वितीय आणि वर्णनात्मक ओळखकर्ता.
• पेलोड स्ट्रक्चर: इव्हेंटमध्ये असलेल्या डेटाचा आकार आणि प्रकार.

उदाहरण:

इव्हेंटचे नाव: userProfile:authenticated

पेलोड:

            {
  "userId": "abc-123",
  "timestamp": "2023-10-27T10:30:00Z"
}

            

              
                Copy
              
            
          

२. नावांसाठी नियम स्थापित करा

नावांचे संघर्ष टाळण्यासाठी, विशेषतः मोठ्या मायक्रो-फ्रंटएंड आर्किटेक्चर्समध्ये, एक सुसंगत नामकरण धोरण लागू करा. उपसर्ग अत्यंत शिफारसीय आहेत.

• स्कोप-आधारित उपसर्ग: [microfrontend-name]:[eventName] (उदा., catalog:productViewed, cart:itemRemoved)
• डोमेन-आधारित उपसर्ग: [domain]:[eventName] (उदा., auth:userLoggedIn, orders:orderPlaced)

३. योग्य अनसबस्क्रिप्शन सुनिश्चित करा

मेमरी लीक्स एक सामान्य अडथळा आहे. नेहमी खात्री करा की जेव्हा घटक किंवा मायक्रो-फ्रंटएंड ज्याने त्यांना नोंदणीकृत केले आहे ते यापुढे सक्रिय नसताना श्रोते काढले जातात. हे विशेषतः सिंगल-पेज ऍप्लिकेशन्समध्ये महत्त्वाचे आहे जेथे घटक गतिशीलपणे तयार आणि नष्ट केले जातात.

            // Example using a framework like React
import React, { useEffect } from 'react';
import { sharedEventBus } from './sharedEventBus';

function OrderSummary({ orderId }) {
  useEffect(() => {
    const subscription = sharedEventBus.subscribe('order:statusUpdated', (data) => {
      if (data.orderId === orderId) {
        console.log('Order status updated:', data.status);
        // Update component state based on new status
      }
    });

    // Cleanup function: unsubscribe when the component unmounts
    return () => {
      subscription(); // This calls the unsubscribe function returned by subscribe
    };
  }, [orderId]); // Re-subscribe if orderId changes

  return (
    

      
Order #{orderId}
      {/* ... order details ... */}
    
  );
}

            

              
                Copy
              
            
          

४. त्रुटी योग्यरित्या हाताळा

जर एखाद्या ग्राहकाने त्रुटी फेकली तर काय होईल? इव्हेंट बसची अंमलबजावणी आदर्शपणे इतर ग्राहकांची प्रक्रिया थांबवू नये. लवचिकता सुनिश्चित करण्यासाठी कॉलबॅक आवाहनांभोवती `try...catch` ब्लॉक्स लागू करा.

५. इव्हेंट ग्रॅन्युलॅरिटीचा विचार करा

अतिव्यापक इव्हेंट्स तयार करणे टाळा जे खूप जास्त डेटा किंवा खूप वारंवार उत्सर्जित करतात. याउलट, असे इव्हेंट्स तयार करू नका जे खूप विशिष्ट आहेत आणि ज्यामुळे इव्हेंट प्रकारांचा स्फोट होतो.

• खूप व्यापक: dataChanged सारखा इव्हेंट निरुपयोगी आहे.
• खूप विशिष्ट: productNameChanged, productPriceChanged, productDescriptionChanged याऐवजी एकाच product:updated इव्हेंटमध्ये विभागले जाऊ शकते, ज्यात काय बदलले आहे हे दर्शवणारे विशिष्ट फील्ड असतात, किंवा डेटाच्या मालकीच्या ऍप्लिकेशनद्वारे हाताळले जाऊ शकते.

तुमच्या सिस्टममधील अर्थपूर्ण स्थिती बदल किंवा कृती दर्शवणारे संतुलन साधण्याचा प्रयत्न करा.

६. इव्हेंट्सचे व्हर्जनिंग

जसजसे तुमचे मायक्रो-फ्रंटएंड आर्किटेक्चर विकसित होते, तसतसे इव्हेंट स्ट्रक्चर्स बदलण्याची आवश्यकता असू शकते. तुमच्या इव्हेंट्ससाठी व्हर्जनिंग धोरणाचा विचार करा, विशेषतः जर बाह्य मेसेज ब्रोकर्स वापरत असाल किंवा अपडेट्स दरम्यान डाउनटाइम हा पर्याय नसेल.

७. ग्लोबल इव्हेंट बस एक सामायिक डिपेंडेंसी म्हणून

जर एक सामायिक जावास्क्रिप्ट इव्हेंट एमिटर वापरत असाल, तर तो तुमच्या सर्व मायक्रो-फ्रंटएंड्समध्ये खरोखर सामायिक आहे याची खात्री करा. वेबपॅक मॉड्यूल फेडरेशनसारखे तंत्रज्ञान हे सोपे करते, कारण ते तुम्हाला जागतिक स्तरावर मॉड्यूल एक्सपोझ आणि वापरण्याची परवानगी देते.

            // webpack.config.js (in host application)
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        catalogApp: 'catalogApp@http://localhost:3001/remoteEntry.js',
        cartApp: 'cartApp@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        './src/sharedEventBus': { 
          singleton: true, 
          eager: true // Load immediately
        }
      }
    })
  ]
};

// webpack.config.js (in micro-frontend 'catalogApp')
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalogApp',
      filename: 'remoteEntry.js',
      exposes: {
        './CatalogApp': './src/bootstrap',
        './SharedEventBus': './src/sharedEventBus'
      },
      shared: {
        './src/sharedEventBus': {
          singleton: true,
          eager: true
        }
      }
    })
  ]
};

            

              
                Copy
              
            
          

इव्हेंट बस केव्हा वापरू नये

इव्हेंट बस शक्तिशाली असली तरी, ती सर्व कम्युनिकेशन गरजांसाठी रामबाण उपाय नाही. ती इव्हेंट्स प्रसारित करण्यासाठी आणि साईड इफेक्ट्स हाताळण्यासाठी सर्वोत्तम आहे. ती सामान्यतः यांसाठी आदर्श पॅटर्न नाही:

• थेट विनंती/प्रतिसाद: जर मायक्रो-फ्रंटएंड A ला मायक्रो-फ्रंटएंड B कडून विशिष्ट डेटा हवा असेल आणि त्याला त्या डेटाची त्वरित प्रतीक्षा करावी लागत असेल, तर इव्हेंट फायर करून प्रतिसादाची अपेक्षा करण्याऐवजी थेट API कॉल किंवा एक सामायिक स्टेट मॅनेजमेंट सोल्यूशन अधिक योग्य असू शकते.
• गुंतागुंतीचे स्टेट मॅनेजमेंट: एकापेक्षा जास्त मायक्रो-फ्रंटएंड्समध्ये गुंतागुंतीचे सामायिक ऍप्लिकेशन स्टेट व्यवस्थापित करण्यासाठी, एक समर्पित स्टेट मॅनेजमेंट लायब्ररी (ज्याचे स्वतःचे इव्हेंटिंग किंवा सबस्क्रिप्शन मॉडेल असू शकते) अधिक योग्य असू शकते.
• गंभीर सिंक्रोनस ऑपरेशन्स: जर त्वरित, सिंक्रोनस समन्वयाची आवश्यकता असेल, तर इव्हेंट बसचे असिंक्रोनस स्वरूप एक गैरसोय ठरू शकते.

मायक्रो-फ्रंटएंड्समधील पर्यायी कम्युनिकेशन पॅटर्न्स

हे लक्षात घेण्यासारखे आहे की इव्हेंट बस हे मायक्रो-फ्रंटएंड कम्युनिकेशन टूलबॉक्समधील फक्त एक साधन आहे. इतर पॅटर्न्समध्ये समाविष्ट आहे:

• सामायिक स्टेट मॅनेजमेंट: Redux, Vuex, किंवा Zustand सारख्या लायब्ररी मायक्रो-फ्रंटएंड्समध्ये सामान्य स्टेट व्यवस्थापित करण्यासाठी सामायिक केल्या जाऊ शकतात.
• प्रॉप्स आणि कॉलबॅक्स: जेव्हा एक मायक्रो-फ्रंटएंड थेट दुसऱ्यामध्ये एम्बेड किंवा कंपोझ केले जाते (उदा., वेबपॅक मॉड्यूल फेडरेशन वापरून), तेव्हा थेट प्रॉप पासिंग आणि कॉलबॅक्स वापरले जाऊ शकतात, जरी यामुळे कपलिंग वाढते.
• वेब कंपोनंट्स/कस्टम एलिमेंट्स: कार्यक्षमता एन्कॅप्स्युलेट करू शकतात आणि कम्युनिकेशनसाठी कस्टम इव्हेंट्स आणि प्रॉपर्टीज एक्सपोझ करू शकतात.
• राउटिंग आणि URL पॅरामीटर्स: URL द्वारे स्टेट शेअर करणे हे संवाद साधण्याचा एक सोपा, स्टेटलेस मार्ग असू शकतो.

अनेकदा, एक व्यापक मायक्रो-फ्रंटएंड आर्किटेक्चर तयार करण्यासाठी या पॅटर्न्सचे मिश्रण वापरले जाते.

जागतिक उदाहरणे आणि विचार करण्यासारख्या गोष्टी

जागतिक प्रेक्षकांसाठी मायक्रो-फ्रंटएंड इव्हेंट बस तयार करताना, या मुद्द्यांचा विचार करा:

• टाइम झोन: इव्हेंट्समधील कोणताही टाइमस्टॅम्प डेटा सार्वत्रिकरित्या समजण्यायोग्य स्वरूपात (जसे की UTC सह ISO 8601) असल्याची खात्री करा आणि ग्राहकांना त्याचा अर्थ कसा लावायचा हे माहित आहे.
• स्थानिकीकरण/आंतरराष्ट्रीयीकरण (i18n): इव्हेंट्समध्ये सहसा UI मजकूर नसतो, परंतु जर ते UI अपडेट्स ट्रिगर करत असतील, तर ते अपडेट्स स्थानिकीकृत करणे आवश्यक आहे. इव्हेंट डेटा आदर्शपणे भाषा-निरपेक्ष असावा.
• चलन आणि युनिट्स: जर इव्हेंट्समध्ये आर्थिक मूल्ये किंवा मोजमाप सामील असतील, तर चलन किंवा युनिटबद्दल स्पष्ट रहा, किंवा त्यांना सामावून घेण्यासाठी पेलोड डिझाइन करा.
• प्रादेशिक नियम (उदा., GDPR, CCPA): जर इव्हेंट्समध्ये वैयक्तिक डेटा असेल, तर इव्हेंट बसची अंमलबजावणी आणि त्यात सामील मायक्रो-फ्रंटएंड्स संबंधित डेटा गोपनीयता नियमांचे पालन करतात याची खात्री करा. डेटा फक्त अशा ग्राहकांना प्रकाशित केला जातो ज्यांना त्याची कायदेशीर गरज आहे आणि त्यांच्याकडे योग्य संमती यंत्रणा आहे.
• परफॉर्मन्स आणि बँडविड्थ: धीमे इंटरनेट कनेक्शन असलेल्या प्रदेशांमधील वापरकर्त्यांसाठी, अति बोलके इव्हेंट पॅटर्न्स किंवा मोठे इव्हेंट पेलोड टाळा. डेटा ट्रान्सफर ऑप्टिमाइझ करा.

निष्कर्ष

फ्रंटएंड मायक्रो-फ्रंटएंड इव्हेंट बस हे स्वतंत्र मायक्रो-फ्रंटएंड ऍप्लिकेशन्समध्ये अखंड, डिकपल्ड कम्युनिकेशन सक्षम करण्यासाठी एक अपरिहार्य पॅटर्न आहे. पब्लिश-सबस्क्राइब मॉडेलचा अवलंब करून, डेव्हलपमेंट टीम्स चपळता आणि टीम स्वायत्तता टिकवून ठेवताना गुंतागुंतीचे, स्केलेबल वेब ऍप्लिकेशन्स तयार करू शकतात.

तुम्ही एक साधा ग्लोबल इव्हेंट एमिटर निवडा, कस्टम DOM इव्हेंट्सचा फायदा घ्या, किंवा मजबूत बाह्य मेसेज ब्रोकर्ससह एकत्रित व्हा, मुख्य गोष्ट स्पष्ट करार परिभाषित करणे, सुसंगत नियम स्थापित करणे आणि तुमच्या इव्हेंट श्रोत्यांचे जीवनचक्र काळजीपूर्वक व्यवस्थापित करणे यात आहे. एक चांगल्या प्रकारे लागू केलेली इव्हेंट बस तुमच्या मायक्रो-फ्रंटएंड्सना वेगळ्या घटकांपासून एका सुसंगत, गतिशील आणि प्रतिसाद देणाऱ्या वापरकर्ता अनुभवात रूपांतरित करते.

तुमच्या पुढील मायक्रो-फ्रंटएंड उपक्रमाची रचना करताना, शिथिल कपलिंग आणि स्केलेबिलिटीला प्रोत्साहन देणाऱ्या कम्युनिकेशन धोरणांना प्राधान्य देण्याचे लक्षात ठेवा. इव्हेंट बस, विचारपूर्वक वापरल्यास, तुमच्या यशाचा आधारस्तंभ असेल.